The intermittent Failed sending HTTP request errors since 2026-07-18 (#181, #182 context) are not a network/transport problem.

GitHub is rolling out a new ~390-char token format (ghs_<id>_<JWT>, "ver":3 in the payload). The dependency clone loop builds its auth header with:

... "AUTHORIZATION: basic $(echo -n "x-access-token:${dep_token}" | base64)"

GNU base64 wraps output at 76 chars. Old tokens (x-access-token: + ~40 chars = 55 chars) fit on one line; new-format tokens produce a multi-line header value, and libcurl rejects headers with embedded newlines — on the runner's curl version this surfaces as Failed sending HTTP request (curl error 55), before a single byte is transferred.

Reproduction

FAKE_TOKEN="ghs_15368_$(printf 'A%.0s' {1..370})"
HEADER="AUTHORIZATION: basic $(echo -n "x-access-token:$FAKE_TOKEN" | base64 | fold -w76)"
git -c "http.https://github.com/.extraheader=$HEADER" clone https://github.com/shopware/SwagExtensionStore.git
# fatal: unable to access '...': A libcurl function was given a bad argument
# (same failure class; message text varies by curl version)

Fix

base64 -w0, exactly like downstream/action.yml:81 already does.

Related findings (separate follow-ups needed)

1. shopware/Rufus .github/actions/setup-rufus/action.yml has the same unwrapped base64 for the masterchief-sdk header — same fix needed there.
2. Re-runs of Downstream workflows fail with could not read Username: the workflow_dispatch payload carries a token from the original upstream run, which is revoked/expired by re-run time. Re-runs of downstream runs can never work this way.
3. ⚠️ That dispatched token is a plain workflow input and is logged unmasked in the job logs (visible to anyone with read access while valid, up to 1 h). Worth a separate security review of the downstream trigger mechanism.